For present purposes, a user interactive data processing system is defined as a system capable of interacting with individual users through input devices (e.g. keyboard, mouse, etc.) and output devices (e.g. displays). A multitasking system is a system in which data associated with multiple processing tasks can be queued in system memory (disk, RAM, etc.) and processed concurrently.
In contemporary user interactive multitasking systems, software resources that control common but rather specialized functions require large amounts of storage space. For instance, the IBM Operating System/2 (OS/2).sup.1 multitasking system contains Presentation Manager (PM) and Spooler subsystems which respectively control display and print job queue management functions of the system. These subsystems occupy over 1 Mb (Megabyte) of system storage space (both on system disks permanently, and in RAM while active). In networks of such systems, it may be necessary to store multiple copies of these subsystems at network stations (on station disks and at times in station RAM's). FNT .sup.1 IBM and operating System/2 (OS/2) are trademarks of the International Business Machines Corporation.
A problem addressed presently is how to efficiently adapt contemporary operating systems, for managing specific tasks on a queued basis other than those normally handled on that basis. The solution presented here is to provide a specialized control utility for each type of "other than normal" task to be managed, which utility per se is incapable of controlling display and queue management functions relative to respective tasks, and to provide interfaces between each such utility and pre-existing presentation and queue management subsystems whereby the latter subsystems are controllable to provide needed display and queue management functions relative to respective tasks. Advantages of this approach are twofold; 1) it reduces time and cost of developing subsystems for managing execution of special tasks in a queued mode, and 2) it decreases the amount of storage space required by the system to manage both tasks which the system has traditionally accommodated and other tasks.
The example that is specifically described here is an adaptation of the OS/2.TM. operating system, to construct a subsystem for managing queued processing of image data; for example, data produced by contemporary document scanning and facsimile reception devices. The OS/2 system per se does not include a task management subsystem of this type. However, by providing a relatively simple control utility for handling image data, which utility per se lacks capability for controlling display and queue controlling functions needed to direct queued processing of associated data, and adapting the utility to interface with the Presentation Manager and Spooler subsystems of that system, an efficiently constituted subsystem for image task management is realized.
The Spooler, which ordinarily only manages queueing of jobs for output devices, such as printers and plotters, is used here to queue document page, image data for associated special processing applications (e.g. conversion of data to forms suitable for display presentation, distribution to databases, printing, etc.). Furthermore, the present task control utility is so constructed that it can directly access queued image data transparent to (i. e. without assistance from) the Spooler. Thus, the utility provides more efficient handling of accessed image data, than it would if it had to invoke the Spooler during such handling, and the system is operated more efficiently inasmuch as the Spooler is free for other uses while the utility is accessing queued image data.